Vehicle networks can be assembled to include networks connected to devices installed by the original equipment manufacturer (OEM), a consumer bus linked to other devices including ports for wireless networks, and a gateway that mediates access among these various devices, as described in the Related Applications. The gateway can be configured to mediate security and external communications. As such, the gateway provides access to telematics services involving remote servers connected through a public network such as the Internet. The gateway, therefore, becomes a resource manager or interface for resources such as communications, data sources, and user interfaces. Thus, the gateway in combination with the networked devices enables a smart vehicle.
In order to capture the potential of automotive telematics systems, many entities will need to be able to connect to the smart vehicles. These entities include retail businesses, automotive OEM suppliers, insurance providers, corporate information technology (IT) organizations, roadway infrastructure providers, and others. These entities must rely on open standards for gaining access to the vehicle. Open standards ensure that all vendors will be able to reach all vehicles and that application developers will have the assurance that their applications are portable and can access the largest market base. Therefore, proprietary extensions to software languages or middleware standards must be avoided—or the portability and validation benefits of these standards will not be obtained.
Serious limitations exist in typical open standards because these standards were developed for conventional IT platforms, for example the desktop computer. The embedded systems of telematics platforms differ from conventional platforms in that they often contain multiple network interfaces and support connections between private vehicle interfaces and external networks. Also, the network connectivity for telematics platforms can require a high cost per unit connect time, (unlike workstation networks). Therefore it is desirable for telematics networking to include integrated cost accounting. Additionally, multiple users may attempt to access shared physical resources in the vehicle such as the audio system, sensors, communications ports and various consumer devices that may be connected to consumer buses. Further, both applications local to the host vehicle and remote applications may attempt access. Conventional systems do not conveniently or securely manage this shared access.
A goal of the telematics community is that local telematics software applications, for example those hosted on an automotive gateway, will deliver compelling safety, security, productivity, and entertainment applications while also enabling the transaction capabilities that will provide revenue. The enabling software infrastructure requires contributions from in-vehicle platform providers, the telematics service provider, and third party independent software vendors (ISVs). This infrastructure and market will be impeded without open and common connectivity and interoperability between vehicles, vendors, and operators. An open standards approach will allow companies to have a uniform way to interface to different vehicle brands. Also, in this way, vendors including petroleum suppliers, convenience restaurants, and other concerns will be better incentivized to connect to the vehicle telematics system if it is the same for different vehicles.
A number of open standards exist currently that provide capabilities for telematics platforms. Generally, these open standards have been developed for conventional desktop computing and other fixed-base applications and are not adaptable to environments where platforms operate in an intermittently connected fashion over a wireless link having a low quality of service along with many other constraints. The primary technologies and available standards include the Portable Operating System Interface (POSIX) standard, the portable software standard, software provisioning standards like the Open Services Gateway Initiative (OSGi), networking standards like wireless point-to-point packet (PPP) communication protocols, security standards like Secure Sockets Layer (SSL), vehicle interface standards like J-1850 and others, local client support standards like Bluetooth, IEEE 802.11, and others, and the Automotive Multimedia Interface Collaboration (AMI-C) standard.
The POSIX defines a standard for a vendor-independent application programming interface (API) between applications and operating systems. The POSIX standard is defined by IEEE 1003, and defines critical operating systems features including those that enable synchronization and scheduling. By following the POSIX standard in selecting the operating system and in development, the portability of the entire platform is maintained. This allows the telematics service provider (TSP) and OEM (e.g., vehicle manufacturer) to make choices for software systems including choices for multiple Java virtual machine (JVM) and middleware vendors. The wide adoption of POSIX standard operating systems means that these systems will carry a large selection of portable JVMs, wireless LAN (local area network) (Bluetooth) interface drivers, protocol stacks, and profiles, as well as other future device drivers and computing platforms.
Open, standard operating systems, including embedded Linux, provide networking, process scheduling, file systems, and security. However, as will be described below in more detail, telematics applications preferentially should make use of additional networking capability for cost-accountable, wireless access, process scheduling for launching and managing multiple applications with controlled process priorities, security for authentication of Gateway platform and applications. These additional networking capabilities are not provided by POSIX.
With reference to the portable software standard, the standard Java Run Time Environment (JRE) provides a hardware-independent platform. The proper operating system and architecture choices allow multiple JVM choices to be selected and to support standard applications. However, Java applications, supported by a virtual machine for example provided on an embedded telematics platform, preferentially should be supported with infrastructure services available in a language-independent fashion. These services include wireless networking, vehicle device, and user interface access. In addition, the JRE faces the challenge for monitoring resource usage, a requirement for managing multiple Telematics applications, hosted on the virtual machine.
The OSGi provides Java application hosting and provisioning. The functions specific to OSGi include installation and uninstallation, process control (starting and stopping an application), service registration, and a security mechanism based on JRE permissions. While OSGi services are effective for provisioning of software to conventional fixed base clients that are equipped with continuous network access, the OSGi standard is limited in management of platforms like telematics platforms that operate in an intermittently connected environment over wireless channels. It is desirable to support OSGi or similar functionality with the proper architecture so that provisioned services are furnished with the appropriate processing priority and have controlled access to secure and accountable networking, as well as other resources.
Networking standards like the wireless PPP communication protocols combined with standard lossless data compression and error correction methods (V.42) can provide a telematics communication substrate, leveraging well-known, cross-industry wireless data communication. Unlike conventional platforms, however, additional support is preferred in telematics platforms to enable the cost accounting so that multiple applications have accountable and fair access to the wireless channel. Also, in addition, automotive telematics carries an unusual burden that applications may exploit multiple wireless channels in a fragmented carrier marketplace. Finally, communication efficiency is more important than in typical broadband applications.
Security standards like SSL transport combined with the Public Key Infrastructure (PKI) offer authentication of embedded platforms, authentication of the Enterprise, message authentication and encrypted communication. In the context of a telematics platform, however, secure networking over these open standards may not be efficiently provided to applications. In particular, networking security may not be provided such that all applications are ensured of security and that the platform is assured that no application may communicate over an unsecured channel or to a network node that is not authenticated in the standard way. It is particularly desirable to ensure that applications do not implement multiple security channels that must be individually validated and may represent security risks.
Because typical vehicle interface standards lack independent interfaces, a vehicle independent interface for telematics applications is desirable to enable portability of applications between vehicles. Also, interfaces to vehicle networks should include security capabilities intended to provide applications with a degree of access that resolves the permissions associated with particular applications. Interfaces should also manage throughput to ensure that applications are not capable of exceeding bandwidth allocations.
The typical local client support standards lack a secure interface that permits authorized applications to gain access to local handheld devices via Bluetooth, IEEE-802.11 interfaces, or other such wireless communications standards as may emerge.
The AMI-C is a worldwide organization of motor vehicle manufacturers created to facilitate the development, promotion and standardization of automotive multimedia interfaces to motor vehicle communication networks. The AMI-C mission is to fill a gap in the current vehicle interface standards by developing a set of common specifications for a multimedia interface to motor vehicle electronic systems in order to accommodate a wide variety of computer-based electronic devices in the vehicle. Implementation of AMI-C capabilities will be facilitated by an open platform based on the standards discussed above.
Turning now to the limitations of typical conventional software architectures in the support of open platforms, it is noted that currently available desktop and enterprise platforms have driven the guiding set of requirements for Java platforms. These have assumed availability of large memory and storage resources and high speed, continuously available Transmission Control Protocol/Internet Protocol (TCP/IP) networking. However, it is desirable to enable a foundation for portable Java applications to support telematics applications that carry networking, resource management, and security objectives that are not met by conventional technologies. It is thus desirable that standard Java, without proprietary extensions, be enabled by appropriate platform infrastructures.
To illustrate these issues, reference is made to FIG. 1, which shows the platform JRE known in the art as it would be hosted on an operating system, which in turn accesses drivers to networking and other devices. The entire software architecture might for example be supported on a platform such as an automotive gateway described in the Related Applications. This standard architecture provides the benefits of application portability (between platforms operating with standard Java platforms and frameworks) and security. The Java 2 security standard implements and defines the “sandbox model” that provides applications with restricted access to specified file systems via a permissions architecture provided by the Java class, java.security.Permission. Also, the Java 2 security standard defines a local namespace that is invoked by the Java platform ClassLoader. Access to resources is controlled by security manger/access controller.
However, examination of this prior art architecture also reveals limitations. In particular, the standard Java platform does not include methods for managing resource assignment to applications. In conventional desktop applications, this may not be a severe limitation in normal usage since determinism is not regarded as the high priority that it is in applications that may involve control system functions. Also, the number of parallel tasks that are normally launched may be small for desktop applications. In contrast, however, telematics systems may support many parallel applications including diagnostics, telematics transaction management, speech processing, media management and media players, networking, and others. Each application should operate with specified priorities and with controlled access to resources that potentially include any or all of the device drivers.
As such, methods should be provided in platforms such that resources including memory and processor cycles can be monitored. This resource monitoring should ensure that system management can limit, terminate, and log an application that has occupied excessive resources. If only one application is running on a JVM, then the operating system may control its global resource usage since the operating system supports the virtual machine (VM) as a conventional process. However, for many parallel applications operating on one JVM, there is no ability in the Java standard for resource consumption management. This requires the solution to protect security and determinism. The platform should additionally provide resource management through standardized, open interfaces while avoiding any proprietary extensions to a particular JRE.
Another limitation of typical conventional software architectures in the support of open platforms is the lack of adequate security. For example, consider FIG. 2, which again depicts a JRE implementation known in the art in a situation where an application has access to wireless network drivers as well as vehicle control drivers. Conventional Java security frameworks permit applications to gain access to device drivers. For example, a diagnostics application may require access to the vehicle control network (for example the J-1850 network) while also enabling wireless access. However, it is required that this application be prevented from operating without security since faults in the application would leave open a path from the wireless environment into the vehicle network. FIG. 2 shows an instance where an application has access to network drivers in this way. Solving this problem by removing access to drivers would be unacceptable to the application developer. Thus, the application developer should have access to a standard and open driver interface that includes control by security permission policy. As for the resource management problem, this technology requirement is more important in telematics and other situations where many users may attempt resource access than in many other applications. Generally, for desktops, access to drivers may remain open.
As for resource management, it is not a problem on conventional computing platforms because network access cost is negligible. For a desktop system, one user maintains responsibility for all network costs and applications all act in support of this user. Further, the use controls the applications and their access. In the case of a cellular telephone microbrowser or pager, again, applications act on the behalf of a single user. However, for telematics, multiple applications may operate in parallel and all may seek network access at specific times. The conventional Java platform allows each application to gain access to network port drivers. FIG. 3 shows the shared access problem of platforms known in the art with an instance where multiple applications all have access to the cellular wireless network device driver. Here it is desirable that proper cost accounting be applied to network access such that the cellular port is not only fairly shared, but, that costs are properly accounted for. There are many similar shared access problems.
Further to the resource management problem found in platforms known in the art, the typical platforms fail to provide a standard, open interface to a network port that includes network traffic cost accounting. This cost accounting should be combined with resource management since the ports in question will be shared by multiple applications.
FIG. 4A shows the OSGi architecture known in the art, including the Java platform architecture. While the OSGi standard specifies methods for delivery and management of applications on remote clients, the standard has many limitations. The standard specification relies on remote service management using servers that access the embedded clients over continuously maintained networks. However, since telematics embedded platforms may operate in an intermittently connected environment, local management of resources and security needs to be added.
The OSGi standard specifies functionality for bundle installation into the Framework, service registration in a registry created by the Framework, distribution of service references to Bundles, distribution of references to other installed Bundles, publish/subscribe methods for Framework events broadcast, and service discovery, log service, and Hypertext Transfer Protocol (HTTP) service Bundles. FIG. 4B is a block diagram of a signed application bundle known in the art. The Bundle components include a Signature Block File (.SF signature and Public Key Certificate), Signature File (Hash entries of all JAR files below), Manifest File (Bundle specific information), and Application Files (Application classes).
The contents of a typical Manifest File for a Service Bundle, LocationService, include the following information: (a) Bundle-Vendor: Sensoria Corporation; (b) Bundle-Version: 1.0; (c) Bundle-Activator: com.sensoria.osgi.impl.gps.GPSSIActivator; (d) Created-By: Sensoria Corporation; (e) Bundle-Name: LocationService; (f) Bundle-ContactAddress: support@sensoria.com; (g) Bundle-Description: GPS Location Service; (h) Export-Package: com.sensoria.osgi.service.gps; and (i) Import-Package: org.osgi.service.log. This manifest file corresponds to a LocationService Service Bundle that might operate on an automotive Gateway platform, for example the gateway available from Sensoria Corporation and described in the Related Applications.
In examining the detailed architecture of the Bundle it is noted that the Export-Package definition contains a package name which is expected to include an interface class. This interface class contained in com.sensoria.osgi.service.gps describes the methods that are available to other Service Bundles that have obtained a reference to LocationService. Also, an Import-Package definition includes a reference to the standard OSGi defined event logging service—org.osgi.service.log.
In addition to defined Export-Package class locations, the Service Bundle implementer also must provide an implementation of the Bundle activator class, which is named in the Bundle-Activator field. This class contains a start( ) method that serves as an entry point to initialize the OSGi Application Framework thread that starts the Bundle application. An important architectural feature is that this method is expected to return immediately, so any Bundle that must implement application functionality must create its own thread(s) in its start method. Thus, all application Service Bundles behave autonomously. This is generally considered an advantage for conventional platforms that operate with resource constraints. However, the autonomous creation of threads, allocation of memory, and occupying of computing cycles all represent concerns for control of the robust and secure platform. There are also resource consumption management issues associated with this autonomy.
Applications operating over the OSGi Application Framework access system services via the Java System Libraries and Java Native Interface, in the usual way. Now, while this may be permissible in some embedded technology applications, this is not applicable to telematics. In telematics applications, the embedded device (Gateway) operates with access to vehicle networks, external Internet connectivity, and local area wireless connectivity. Thus, the embedded platform now contains a routing and bridging function. Thus, the security requirements for this platform are drastically more significant since the embedded platform can, in principle, enable network access between private vehicle services and the external Internet or other local devices. This security risk points towards a need for new solutions. However, it is desirable for reasons of rapidity of application development that these solutions be provided without introducing proprietary OSGi extensions.
Limitations of conventional extensions of open software architectures are now described. Telematics applications are likely to appear in a variety of forms. Consider for example the following two categories: (1) compact Java telematics applications that are provisioned over the wireless network via application Service Bundles using the OSGi standard; and (2) large footprint, legacy applications that are part of the embedded telematics platform services and may be frequently available only as native (C or C++) code distributions. Examples of the first category are applications that schedule transactions and may be rapidly and frequently “swapped” by the Telematics Service Provider to enable the Gateway to respond to evolving customer requirements. Examples of applications in the second category are speech recognition, media player, navigation applications and other services that are compute intensive or require particularly fine control over large memory allocations. Support of either of these applications often requires device drivers, networking stacks, and networking profiles for Bluetooth and IEEE-802.11 wireless LAN interfaces that are implemented in native code.
There are multiple approaches for providing interfaces between the Java telematics applications and native platform services. The most commonly proposed approach depends on Java Native Interface (JNI) implementations with proprietary APIs. FIG. 5 is a block diagram of Java applications communicating via JNIs as known in the art.
This architecture illustrates the conventional method for communication between the telematics applications and both the Java JRE and native code applications. It is clear that a special API implemented with the Java Native Interface must be introduced because the proprietary APIs are an extension of the Java standard and limit portability of Java applications. In addition, separate validation steps are required for the integration of Java and native code via this conventional method.
In the drawings, the same reference numbers identify identical or substantially similar elements or acts. To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the Figure number in which that element is first introduced (e.g., element 1012 is first introduced and discussed with respect to FIG. 10).
Figure numbers followed by the letters “A,” “B,” “C,” etc. indicate either (1) that two or more Figures together form a complete Figure (e.g., FIGS. 10A and 10B together form a single, complete FIG. 10), but are split between two or more Figures because of paper size restrictions, amount of viewable area within a computer screen window, etc., or (2) that two or more Figures represent alternative embodiments or methods under aspects of the invention.
The headings provided herein are for convenience only and do not necessarily affect the scope or meaning of the claimed invention.